2023-08-10 Техзавдання

Техзавдання

Техзавданням називається Технічне завдання об'єднане з Технічним ескізом архітектури системи. Техноробочим проєктом називається Технічний проєкт об'єднаний з Технічною документацією системи. Даний документ представляє собою перший вид — Техзавдання.

Згідно ДСТУ 3973-2000 "Система розроблення та постачання продукції на виробництво. Правила виконання науково-дослідних робіт. Загальні положення" Технічне завдання повинно включати наступні пункти: Мотивація, Мета, Виконавці, Вимоги, Етапи, Результати, Документація, Порядок передачі, Вимоги до даних.

Згідно ДСТУ 3974-2000 "Система розроблення та постачання продукції на виробництво. Правила виконання науково-конструкторських робіт. Загальні положення" на стадії проектування Ескізний проект і технічний проект повинні містити архітектуру системи.

Технічне завдання

Науково-дослідні роботи.

Мотивація, Мета, Виконавці

Головна мотивація — створення безкоштовного відкритого українського захищеного месенжера. Мета та місія — популяризація обізнаності в області клаліфікованого українського цифрового підпису. Виконавці завдання повинні мати експертизу в обсласті стеку протоколів ASN.1 та володіти DER компілятором під одну з віртуальних машин, або генерувати C/Swift код. Також виконавці повинні мати обізнаність з протоколів брокерів типу IRC, XMPP, AMQP, MQTT. Також виконавці повинні мати відділ криптографії.

Класифікація вимог

Маркетинговий відділ разом з відділом проєктування і докумнутавання через консультації з відповідними відділами формують класифікацію вимог згідно вимог документування.

1) Класифікація: функціональні, технічні, адмін, ергономічні, політичні, юридичні.
2) Принципові вимоги. Формує відділ маркетингу.
3) Функціональні вимоги. Формує головний офіс.
4) Ергономічні вимоги. Формує сектор клієнтської розробки.
5) Технічні вимоги. Формує відділ документування та проектування.
6) Адміністративні вимоги. Формує сектор серверної розробки.
7) Політичні вимоги. Формує маркетинговий відділ.
8) Юридичні вимоги. Формує юридичний відділ.
9) Документальні вимоги. Формує відділ документування та проектування.
10) Архітектурні вимоги. Формує відділ документування та проектування.

Принципові

Принципові особливості. Користувач повинен мати можливість контролювати типи кривих і ключ для кожного облікового запису або навіть для кожного повідомлення. Усі повідомлення, які користувач надсилає або отримує підписуються та шифруються цими ключами, зашифровані копії при цьому не зберігаються на сервері.

Відкритість та прозорість для аудиту. Повний вихідний код ЧАТ X.509 клієнтів і серверних рішень доступний на GitHub. Це дає змогу зацікавленим сторонам перевірити код на безпеку та правильність.

Відповідність світовим та державним телекомунікаційним та криптографічним стандартам NIST, ISO, ANSI, ITU, FIPS, ДСТУ, ДССЗІ.

NIST: SP 800 38D-56A-57-162, P-384, P-571;
ISO: 20922 15946 10646 8824 8825;
ANSI: X9-64, X9-62;
FIPS: PUB 180-4;
ДСТУ: 4541 28147 GF(2^509);
ITU: X.509 (PKI), X.894 (CMS), X.680-X.683 X.690-697 (ASN.1);
ДССЗІ: #112 14.05.2010 #1236/5/453 20.08.2012 #687 27.10.2020

Протокол системи. Протокол системи повинен відповідати CHAT ASN.1 специфікації. Відповідні клієнти повинні генеруватися для Swift найсучаснішими бібліотеками від Apple.

1) Чат протокол
2) Контакти
3) Записна книжка
4) Аунтентифікація та реєстрація
5) Повідомлення
6) Топіки та групи
7) Профілі та сервера
8) Передача файлів
9) Пошук по директорії
10) Френдування профілів
11) Налаштування

Функціональні

Повний перелік фукнціональних історій користувача поекранно (27 екранів у відповідності до ергономічних вимог).

Вхід в систему. Повинен зображати логотип компанію можливість зміни мови на англійську, доступ в 1 клік до ліцензії користувача (EULA) та використаних субліцензій (Ліцензії). Також головний режим повинен пропонувати наступні варінти розвитку подій: 1) реєстрація; 2) аутентифікація через останній використаний профіль; 3) імпорт профілю з файлу. Всі варіанти окремими екранами.

Центр сертифікації. При реєстрації месенжер повинен використовувати CMP/CMC/EST сервер для видачі нових сертифікатів. Потрібна підтримка повного переліку схем узгодження ключів які є в технічних вимогах цього технічного завдання.

Сертифікатне сховище. Ключі повинні зберігатися у сертифікатному сховищі, у відповідності до системних стандартнів операційної системи.

Реєстрація. Сторінка повинна давати можливість вибрати один з трьох варіантів реєстрації: 1) реєстрація на nickname (анонімна); 2) реєстрація на телефон (частково ферифікована); 3) реєстрація через пошту (верифікація через домен).

Угода користувача. Разом з реєстрацією користувачу приходить угода яка є дійсною на час створення аккаунту End User License Agreement (EULA).

Профіль користувача. Одразу після реєстрації і підтвердженні угоди користувача за замовчуванням клієнт переходить в екран профілю користувача або в екран приватності, про який повинно бути розказано в EULA. На екрані профілю користувача повинно бути доступне в нижній частині меню на 4 пункти які ведуть в 4 різні екрани додатку.

Налаштування приватності. Екран приватності надає доступ до таких функцій: 1) Синхронізація контактів з iOS; 2) Блокування невідомих (викл); 3) Ділитися контактами з iOS (викл); 4) Заблоковані корістувачі (список); 5) Номер телефону (сторінка підтвердження); 6) Email (сторінка підтвердження); 7) Видимість в загальному каталозі (викл); 8) Відвідини та стан мережі (сторінка); 9) Фото профілю (сторінка); 10) Виклики (список); 11) Голосові повідомлення (список); 12) Пересилання повідомлень (сторінка); 13) Додавання мене в групах (сторінка); 14) Звіт про прочитання (викл); 15) Індикатор набору тексту (викл); 16) Папки для чатів (сторінка); 17) Таймер автовидалення (сторінка). На екрані приватності користувача повинно бути доступне в нижній частині меню на 4 пункти які ведуть в 4 різні екрани додатку.

Список контактів. Користувач повинен мати змогу бачити повний перелік своїх контактів доданих до спілкування на залогіненому профілі. Користувач може видалити, додати нового, перейти в редагування контакту для зміни інформації про нього, аватару, тощо. Користувач повинен мати змогу пошуку в глобальній директорії нових користувачів які дозволили себе шукати в директорії або на підприємствах це є політикою за замовчуванням. Також на екрані приватності користувача повинно бути доступне в нижній частині меню на 4 пункти які ведуть в 4 різні екрани додатку.

Перегляд та редагування контакту. Користувач повинен маги змогу бачити всю атрибутивну інформацію контакту та можливіть її редагувати.

Топіки. Користувач повинен бачити топіки системи, шукати по опису, або створювати новий. Топіки -- це узагальнена назва для каналів, груп, та інших видів комунікації які передбачають використання криптографічного протоколу MLS.

Кімната топіку. Кімната топіку представляє собою узагальнений комунікаційний стрім з батьма учасниками. Користувач повинен мати змогу надсилати повідомлення, читати повідомлення групи, його клієнт повинен реагувати на оновлення ключів в протоколі MLS, а також клієнт повинен відображати Spring Bubbles ефект на екрані з повідомленнями.

Налаштування топіку. Кожен топік або група, повинна мати екран з налаштуваннями, функціональність яких залежіть від ролі учасника групи. Адміністратори групи можуть додавати членів групи, кікати з групи, встановлювати бани, редагувати атрибутивну інформацію групи.

Чати. Екран з переліком чатів в профілі з пошуком, яки показується верхнім свайпом, повинен містити папки, які можна налаштувати для профіля в налаштуваннях профіля. Системна папка "Всі" містить візуально виділені групи закріплених повідомлень у той час як інші створені папки містять негруповані переліки чатів.

Системні параметри. Системні параметри знаходяться на сторінці профілю, так само як і параметри додатку. Сюди входять: 1) Геопозиція; 2) Контакти; 3) Фото; 4) Локальна мережа; 5) Мікрофон; 6) Спектральний аналіз мовлення; 7) Камера; 8) Сповіщення; 9) Стільникові дані.

Експорт профілю. Сторінка експорту профілю з 12 фразами які користува вводив на екрані імпорту профілю.

Сховище і дані. Налаштування сховища і папок дає доступ до наступних функцій: 1) Керування сховищем; 2) Налаштування папок; 3) Медіа.

Папки. Користувач повинен мати змогу редагувати імена папок та переносити повідомлення з однієї папки в іншу. Функції: 1) Сторити папку; 2) Перегляд папок; 3) Рекомендовані папки.

Сповіщення та звуки. Функції: 1) Звук; 2) Вібрація; 3) Попередній перегляд; 4) Вибір сигналу; 5) Вибір сповіщення.

Сервери. Користувач повинен мати змогу окремо контролювати налаштування всіх зовнішніх серверів CA, NS, LDAP, CHAT.

Новий сервер. Користувач повинен мати змогу створити новий сервер для спілкування, пошуку по директорії, для використання таблиці імен чи для отримання TLS сертифікату.

Ергономічні

Повний перелік iOS екранів.

1) Запрошення (010-WELCOME);
2) Ліцензії (020-LICENSE);
3) Угода користувача (030-EULA);
4) Реєстрація (040-REG);
5) Реєстрація на мобільний (050-MOBILE, 051-MOBILE-VERIFY);
6) Реєстрація на пошту (060-MAIL, 061-MAIL-VERIFY);
7) Реєстрація анонімна (070-IDENT);
8) Імпорт профілю (080-IMPORT);
9) Профіль користувача (090-PROFILE);
10) Приватність (100-PRIVACY);
11) Контакт (110-CONTACT);
12) Контакти (120-PERSONS);
13) Новий контакт (130-FRIEND);
14) Топіки (140-TOPICS);
15) Кімната топіку (150-ROOM);
16) Налаштування топіку (160-ROOM-SETTINGS);
17) Чати (170-CHATS);
18) Чат (180-MESSAGES);
19) Папки (190-FOLDERS);
20) Системні параметри (200-SYSTEM);
21) Експорт профілю (210-EXPORT);
22) Сховище і дані (220-STORE);
23) Сповіщення та звуки (230-NOTIFICATIONS);
24) Сертифікати (240-KEYS);
25) Сертифікат енролмент (250-CERT-ENROLL);
26) Сертифікатне представлення (260-CERT);
27) Сервери (270-SERVERS);
28) Новий сервер (280-NODE);

Технічні

Швидкодія. Граничні показники latency для контактної книги з 1000 елментів, латенсі на додавання нового користувача, латенсі на пересилання повідомлення, тощо.

Телекомунікаційна повнота. Система повинна підтримувати наступний перелік стандартів і протоколів ITU, ANSI, ДСТУ конвертів визначених в ASN.1 нотації. Кожен клієнт CHAT X.509 повинен мати змогу підтримувати більшість з цих визначень, але не кожен публічний компілятор ASN.1 підтримує всі файли.

AESKeyWrapWithPad-02.asn1, AESKeyWrapWithPad-88.asn1, ANSI-X9-42.asn1, ANSI-X9-62.asn1, AlgorithmInformation-2009.asn1, AttributeCertificateVersion1-2009.asn1, AuthenticationFramework.asn1, BasicAccessControl.asn1, CHAT.asn1, CMS-AES-CCM-and-AES-GCM-2009.asn1, CMSAesRsaesOaep-2009.asn1, CMSECCAlgs-2009-02.asn1, CMSECDHAlgs-2017.asn1, CertificateExtensions.asn1, Character-Coding-Attributes.asn1, Character-Presentation-Attributes.asn1, Character-Profile-Attributes.asn1, Colour-Attributes.asn1, CryptographicMessageSyntax-2009.asn1, CryptographicMessageSyntax-2010.asn1, CryptographicMessageSyntaxAlgorithms-2009.asn1, DOR-definition.asn1, Default-Value-Lists.asn1, DirectoryAbstractService.asn1, Document-Profile-Descriptor.asn1, EnrollmentMessageSyntax-2009.asn1, ExtendedSecurityServices-2009.asn1, External-References.asn1, Geo-Gr-Coding-Attributes.asn1, Geo-Gr-Presentation-Attributes.asn1, Geo-Gr-Profile-Attributes.asn1, ISO-STANDARD-9541-FONT-ATTRIBUTE-SET.asn1, ISO9541-SN.asn1, Identifiers-and-Expressions.asn1, InformationFramework.asn1, KEP.asn1, LDAP.asn1, Layout-Descriptors.asn1, Link-Descriptors.asn1, Location-Expressions.asn1, Logical-Descriptors.asn1, MultipleSignatures-2010.asn1, OCSP.asn1, PKCS-10.asn1, PKCS-12.asn1, PKCS-5.asn1, PKCS-7.asn1, PKCS-8.asn1, PKCS-9.asn1, PKIX-CommonTypes-2009.asn1, PKIX-X400Address-2009.asn1, PKIX1-PSS-OAEP-Algorithms-2009.asn1, PKIX1Explicit-2009.asn1, PKIX1Explicit88.asn1, PKIX1Implicit-2009.asn1, PKIX1Implicit88.asn1, PKIXAlgs-2009.asn1, PKIXAttributeCertificate-2009.asn1, PKIXCMP-2009.asn1, PKIXCRMF-2009.asn1, Raster-Gr-Coding-Attributes.asn1, Raster-Gr-Presentation-Attributes.asn1, Raster-Gr-Profile-Attributes.asn1, SMIMESymmetricKeyDistribution-2009.asn1, SecureMimeMessageV3dot1-2009.asn1, SelectedAttributeTypes.asn1, Style-Descriptors.asn1, Subprofiles.asn1, Temporal-Relationships.asn1, Text-Units.asn1, UpperBounds.asn1, UsefulDefinitions.asn1, Videotex-Coding-Attributes.asn1.

Криптографічна повнота. Система повинна підтримувати всі криптографічні примітиви згідно визначених стандартів, таких як CMS, і для яких існують ASN.1 oid ідентифікатори: gost28147-ofb/cfb/wrap, Dstu7624-cfb/ofb-x256, ecPublicKey, secp192r1, secp256r1, ECDSA-sha/sha224/sha256/sha384/sha512, DSA, DSA-SHA1, RSA, MD2-RSA, MD5-RSA, SHA1-RSA, SMIME, ESDH, SSDH, CMS-3DES/RC2-wrap, MD2, MD5, HMAC-224/256/384/512, RC2-CBC, DES-EDE3-CBC, keyExchange, AES-128/192/256-ECB/CBC/GCM/CCM/wrap/wrap-pad, DSA-sha224/256, 1pass-HKDF-SHA/256-384-512, 1pass-KDF-SHA/224-256-384-512, HMAC-SHA1, SHA1, SECT163k1, SECT163r2, secp224r1, sect233k1, sect233r1, id-ecDH, id-ecMQV, 1pass-cofactor-KDF-SHA/224-256-384-512, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1 sect571r1, x9-63.

Адміністративні

1) Вимоги до ресурсів;
2) Вимоги до розгортання;
3) Вимоги до адміністрування;
4) Вимоги до архівування;
5) Вимоги до мігрування.

Політичні

1) Вимоги до маркетингового позиціонування;
2) Вимоги до сховища даних;
3) Вимоги до мов програмування;
4) Вимоги до середовища виконання;
5) Вимоги до апаратури;
6) Вимоги до архітектури;
7) Вимоги GDPR;
8) Вимоги до API SDK;
9) Вимоги до Open Source.

Юридично-правові

1) Використані ліцензії;
2) Ліцензійна угодна про використання сервісу (EULA);
3) Типові контракти з ЄДРПО;
4) Типові контракти з ФОП;

Документування

Вимоги до стандартів документування. Всі документи (зокрема цей докуент) повинні відповідати новим стандартам ДСТУ: 3008:2015, 3973-2000, 3974-2000, 3396.0-96, 3396.1-96, 3396.2-97, 2844-94, 2873-94, 2941-94, 3919-99, 2851-94, 2853-94, 4071–2001, 4072–2002, 4249:2003, 4302:2004, 4145:2002; ISO/IEC: 2382-4:2005, 2382-5, 2382-9, 2382-14, 2382-15, 2382-17, 2382-18, 90003:2006, 14369:2003, 9126-1:2013, 12207:2014, 12182:2004, 14598-1-6, 14764:2014, 15288:2014, 15504-1:2002, 9735-1:2005, 20625:2006, 13888-1,3, 14888-1-3, 10118-1-3, 15946-1, 18014-1-2, 9798-1,3:2015, 13335-1,5, 29101:2018, 11770-6:2018, 17023:2018, 18370-1:2018. А також бути сумісними з недійсними стандартами: ДСТУ 19.403-404, 19.501-508, 19.601-604, 19.701, 19.781. ДСТУ 34.003, 34.201, 34.601-602, 50-34.698, 50-34.682.

Вимоги до набору документів. Набір включає наступні документи:

1) Технічні характеристики (Datasheet);
2) Брошура та головний сайт (Whitepaper);
3) Посібник користувача (Manual);
4) Слайди презентації (Slides);
5) Діаграми Ґанта (Gantt);
6) Вимоги та технічне завдання (Requirements);
7) Публікації (Publications);
8) Архітектура та програмування (Book);
9) Ліцензії та угода користувача (EULA);
10) Субліцензії (Licenses);
11) Контракти (ЄДРПО);
12) Контракти (ФОП);
13) Комплекс систем захисту інформації (КСЗІ).

Етапи

Домовленність про майлстойни та фази реалізації. Імплементація виглядає як простий сервер доставки миттєвих повідомлень розроблений для ненадійних мереж та у відповідності до стандартів ISO/IETF.

1) Перший етап: протокол X.509, iOS клієнт, P2P чати;
2) Другий етап: групові чати, голосові чати;
3) Третій етап: P2P відео чати;
4) Четвертий етап: групові відеочати RTP.

Результати

Очікувані результати:

1) Пакети програм;
2) Документація;

Порядок передачі

Порядок передачі визначає передачу реалізації і документації шляхом публікації в репозиторії Github організації CHAT-X509 використовуючи GPG підпис представника виконавця.

Ескізний проєкт

Науково-конструкторські роботи. Згідно ДСТУ 42010:2018 "Інженерія систем і програмних засобів. Опис архітектури" ескізний проект подається у вигляді фреймворку Закмана або ДСТУ 62264:2019 "Інтеграція систем управління підприємством і виробництвом" і формується відділом документування та проектування під керівництвом головного архітектора системи та містить наступні частини:

1) Таксономія системи. Сервера, Модулі, Функції;
2) Регламент взяємодії. Інформаційні зв'язки системи. Протоколи;
3) Схеми даних: реляційні і неряляційні моделі;
4) Форми взаємодії: атрибутивна модель клієнта та його форм;
5) Правила доступу: бізнес-процеси системи, права та логіка.

Таксономія системи

Сервер повинен бути представляти собою сервер доставки миттєвих повідомлень розроблений для ненадійних мереж та у відповідності до стандартів ISO/IETF. Він повинен використовувати шину та брокер MQTT, LDAP сервер для корпоративних ієрархічних конфігурацій, та бінарну серіалізацію DER (ASN.1). CHAT повинен складається з наступних додатків:

1) MQTT у якості Pub/Sub ABAC брокера;
2) LDAP для директорії користувачів;
3) DNS для безпеки іменного простору;
4) CA для CMS криптографії та PKIX серверів OCSP, TSP, CMP;
5) Swift iOS клієнт;
6) Elixir консольний клієнт.

Регламент взаємодії

1) TCP — сесійний протокол;
2) MQTT — сесійний протокол брокера;
3) TLS — безпечний канал захищений сертифікатом;
4) CMP — сервер видачі сертифікатів X.509;
5) CMS — бібліотека криптографічних повідомлень X.894;
6) DNS — сервер імен;
7) LDAP — сервер директорії підприємства;
8) TSP — серве позначки часу для цифрового підпису;
9) OCSP — сервер перевірки відкликаних сертифікатів;
10) CHAT — сервер чат протоколу.

Схеми даних

1) Схема LDAP;
2) Схема CA: CMP/CMC/EST, CMS, OCSP, TSP;
3) Схема NS: DNSSEC;
4) Схема CHAT: FORM, KVS, LDAP.

Форми взаємодії

27 екранів системи, їх атрибутивна інформація та внутрішня логіка на Swift описана в документації та документація на бібліотеку FORM яка генерує форми на сервері для відображення на клієті і без прошитих форм на клієнті.

Правила доступу

1) Політики безпеки MQTT;
2) Політики безпеки DNS;
3) Політики безпеки CA;
4) Політики безпеки LDAP;